Remarks 

Comments in Response to Examiner 



Applicants submit that in the Appeal Brief a SIP message is given as an example of a 
signalling protocol message (see page 5 line 5). As stated in the Appeal Brief signalling 
protocol messages or messages are exchanged between machines for some purpose, for 
example establishing a media session between user terminals. Signalling protocol 
messages are not visible to end users. 

The Examiner states that "signalling protocol message" is not defined in the specification and 
the Examiner is left to interpret this term in the light of the applicant's disclosure and the 
relevant prior art. The disclosure of the patent application should be read through the eyes 
of the skilled artisan. However, signalling protocol messages are well known in the art - 
where they are used to manage dialogues between end-user application processes and 
would not be understood as being limited to SIP. One skilled in the art would understand 
that group of protocols known as signalling protocols include, for example, SS7, SIGTRAN, 
H.323, and BICC in addition to SIP. Furthermore, one skilled in the art would recognize that 
an email message is not included in the group of messages called signalling protocol 
messages. 

Minor Informalities 

Claim 2 has been amended to end with a period. 
Drawings 

New Figure 16 is filed herewith to remove the handwritten features in Figure 16. 
Claim Reiection - 35 USC §112 

Claim 3 has been amended to recite the limitation "a caller". Applicants submit that "the 
identity" requires no antecedent as it belongs to the caller and all callers will have an identity. 
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Claim 8 has been amended to remove the "the access configuration information". It has also 
been amended to depend from Claim 7. 

Claim 10 has been amended to recite " a called party". 
Claim Rejections - 35 USC S102 

Claims 1 has been amended to recite "storing computer software codes in at least one 
signalling protocol message". Applicants submit that this limitation does not correspond to 
the use of JavaBeans, serveiets or applets within a SIP communication network as claimed 
by the Examiner. This is because the computer software code now needs to be stored 
within the message rather than merely associated with it. 

The Examiner rejects Claims 1, 7 to 8, 11 and 14 as being anticipated by Anjum. Applicants 
submit that Anjum does not disclose "storing computer software code in at least one 
signalling protocol message" as claimed in Claim 1. 

Paragraph 2 of the paper, states that "(1) Alice, the user of terminal A, invites Bob, who is 
using terminal B, to a communication session where they can use a whiteboard to share 
information; (2) A issues the whiteboard session invitation to B; (3) unfortunately, B does 
not have the whiteboard software installed, and it informs A accordingly; (4) A suooests a 
location on the Internet where the software can be obtained : (5) B downloads the software, 
negotiating one-time use payment with the software provider if the software is not public- 
domain; (6) B sets up a white-board session with A so Alice and Bob can communicate" 
(emphasis added). The article also states that in the prototype they "designed a version of 
SIP, called extended SIP. for session initiation which defines a small set of extensions to SIP, 
for supporting advanced services." (page 23. left column, paragraph 2). 

Figure 6 illustrates the signalling protocol messages sent between the terminals of user A 
and user B. These messages are described in paragraph 2 of the section entitled "Dynamic 
Service Download" in the right column of page 27. This paragraph describes "INVITE 
message" which is sent from the terminal of user A to the terminal of user B when user A 
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indicates that tiiey wish to communicate with user B using a certain type of media. The 
"UNSUPPORTED _ MEDIA message" is sent from terminal as user B to the terminal of user 
A if the media is not supported by the terminal of user B. The terminal of user A can then 
provide a suggestion to the terminal of user B, indicating a service provider, which may be 
accessed through a URL and may be able to supply the resource. This is shown as "INVITE 
(URL)" in Figure 6. "Suspend" message can be sent whilst the terminal of user B negotiates 
with the provider if user B accepts the suggestion. 

Applicants submit that all that is disclosed as being transmitted between the terminals of user 
A and user B is an INVITE message which is "indicating a service provider" (page 27 right 
column second paragraph) and that the service provider is "reachable through a URL". 
There is no disclosure of the URL being embedded within the SIP message. However, even 
if the URL were embedded within the SIP message, which is not admitted, Applicants submit 
that a URL is simply a location address on a network comprising no more than a set of 
characters. A URL does not and could not perform any function other than provide a 
location address. 

RFC 2396 is the standard definition of URLs such as http:, ftp: and so on. For the 
Examiner's reference, a document entitled "A Beginners Guide to URLs" is enclosed. This 
document is a standard primer issued by the National Center for Super Computing 
Applications in the eariy days of the Internet to explain the function of any uniform resource 
locator (URL) which includes SIP URLs. A URL is merely a pointer to a resource within a 
network. Thus a URL is data which can be parsed by computer software code in order to 
determine the network location of a resource. It is not software code. 

In the case of a SIP URL (as explained on pages 20-25 of Handley), the resource typically is 
a user end station which is to be contacted using the SIP protocol. This is directly analogous 
to a user picking up a conventional telephone handset and dialling a telephone number; in 
which case the URL is the telephone number. On no level does this action or a SIP URL 
equate to executable computer programs. 

As noted in RFC 2396 (the fundamental definition of a URL) a URL is a subset of the set of 
uniform resource indicators (URI) all of which "provide a simple and extensible means for 
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identifying a resource" (see section 1.0 RFC 2396), RFC 2396 continues by explaining that 
"having identified a resource, a system may perform a variety of operations on the resource, 
as might be characterised by such words as "access", "update", "replace", or "find attributes"". 
Thus a URL is never executed. Instead, a URL may be used to point to a resource which 
may itself be executed. 

Applicants therefore submit that Claim 1 is not anticipated by Anjum. 

Claim 14 recites a destination terminal controlled by "a processor arranged to access any 
computer software code stored in received signalling protocol messages". Therefore 
Applicants submit that Claim 14 is also not anticipated by Anjum. 

Applicants submit that Claims 2 to 11 and 15 are not anticipated by Anjum at least by virtue 
of their dependencies. 

Withdrawn Claims 

Claims 12-13 and 16-24 have been cancelled as requested. 

In view of the above, further and favorable reconsideration are urged. 

April 22. 2005 Respectfully subnnitted, 
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